COMMENT ⊗   VALID 00008 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	@Device[DOVER]
C00005 00003	@Comment( from THESIS )
C00016 00004	@Comment( from THESIS )
C00022 00005	@Comment( from SCENAR )
C00028 00006	@SubSection(Examples)
C00030 00007	@Comment( from SCENAR )
C00033 00008	@Section(Further tasks)
C00041 ENDMK
C⊗;
@Device[DOVER]
@Make[Article]

@DefineFont(BodyFont,	
	R=<Xerox "TimesRoman10R">,
	I=<Xerox "TimesRoman10I">,
	B=<Xerox "TimesRoman10B">,
	P=<Ascii "TimesRoman10BI">,
	F=<Xerox1 "Gacha10R">,
	C=<Xerox "TimesRoman8R">,
	Z=<Ascii "MATH10R">,
	G=<Xgreek "Hippo10R">,
	Y=<Xerox "TimesRoman8R">,
	X=<Xerox "Symbol10R">,
	U=<Ascii "Sail10">,
	T=<Xerox1 "Gacha10B">)

@DefineFont(SmallBodyFont,
	R=<Xerox "TimesRoman8R">,
	B=<Xerox "TimesRoman8B">,
	I=<Xerox "TimesRoman8I">,
	P=<Xerox "TimesRoman8BI">,
	G=<Xgreek "Hippo8R">,
	F=<Xerox1 "Gacha8R">,
	Z=<Ascii "MATH8R">,
	Y=<Xerox "TimesRoman8R">,
	X=<Xerox "Symbol10R">,
	U=<Ascii "Sail8">,
	C=<Xerox "TimesRoman6R">,
	T=<Xerox1 "Gacha8B">)
@Modify[Verbatim, Break Before]
@Modify[Description, Spread 0, Spacing 1.3]
@Modify[Quotation, Indent 0]
@Use(Bibliography = "REPN.BIB[RDG,DBL]")
@Use(Bibliography = "META4.BIB[RDG,DBL]")
@Style[Indent 0]
@Style[References=STD Alphabetic]
@DEFINE[Aside=NoteStyle, LeftMargin -16, Indent 0]
@DEFINE[SubAside=Quotation,Font SmallBodyFont,FaceCode I,Spacing 1,Spread 0.5]
@DEFINE[Subsubsection,Use HdX,Font TitleFont3,FaceCode I,Above .3inch,Centered]
@DEFINE[ENUM1=ENUMERATE, NumberFrom 0, SPREAD=0]
@SET[Page=1]

@EQUATE[YY=R]
@SpecialFont[F1=TimesRoman14]
@Font[TimesRoman10]

@Counter(EquationCounter, Numbered <(Facts @1)>, Referenced <(Facts @1)>,
IncrementedBy tag, INIT 0)
@Comment( from THESIS )
@Begin[Center]
@F1[Using Analogies For Knowledge Acquisition]

Russell Greiner
@End[Center]

@Section[Introduction]
@Tag(Intro)

@i<This paper is a mishmash, taken from various documents, including
my thesis proposal, an example scenario,
and a short (proto)paper on "naive analogy".
The various "unbound" pointers refer to sections in those documents.>

Analogy plays a role in much of the reasoning processing which
people use everyday.
Analogical reasoning is required to understand metaphors 
(as in "she's a packrat") and
similes (like "he eats like a bird"),
as well as many forms of explanations --
when one phenomenon is described in terms of 
(that is, using the model defined by) another,
as seen in the common
"electicity can be understood using the model by water flow" analogy,
or "consider the atom to be a small solar system".
Much of our speech is laced with "extended" meanings, based on metaphors
we had not realized we were using.
We, for example, consider time a precious commodity,
("he didn't have the time to give"),
indicate emotional makeup in terms of spatial (up versus down) position,
("he was feeling down this morning")
and even consider speech to be "laced".

Such evidence supports the view that the ability to generate and comprehend
an analogy is a tremendously useful and powerful tool
-- not only for allowing efficient communication,
but also for (increasing our) "understanding" of parts of the world.  
This research has two goals.
We will first present a formal cognitive model which
accounts for/explains much of the phenomenon of analogy,
The second goal is the implementation of a computer program which uses
(a subset of this) this analogical capability.
In particular,
this program will permit a user to describe a new term (to an expert system)
by analogy -- 
that is, defining such terms as analogues of some existing terms.

This research begins with a definition of (our usage of) the term "analogy",
and a mechanism for deciding how good or appropriate an analogy is.

We are defining an analogy as a shared partial theory.
That is, two objects are analogous if they each satisfy the same
common partial theory, or cpt. (See @Cite(M&M).)
In the example which follows, the cpt was <@i(Hierarchy)>, the theory of
hierarchies.@FOOT{
This definition has much in common with both
@Cite[Hesse]'s "formal analogies",
and the notion of "ground" used in @Cite[Paivio] (in the context of
"topic, vehicle and ground").}

This definition differs from the more standard "mapping approach," using
by most researchers -- including 
@Cite(Winston), @Cite(Carbonella), @Cite(Kling), @Cite(RBrown), 
@Cite(Gentner), @Cite(Hesse) (and, from learning, @Cite(Learn-HR)).
In these works, analogy is considered a mapping,
connecting some attributes of one analogue to corresponding attributes of the other.
As Subsection @Ref(UseOfAnswer) points out, corresponding attributes
of the analogues can be associated using the "common subtheory" approach as well.
The (easier to describe) feature matching method does work quite well
when the only correspondences are at a "surface" level -- 
e.g. when the relevant properties to match
are things like number of deaths, or particular steps in a proof.
It runs into quite a bit of trouble mapping "deeper structures"@Foot{
While related, this should NOT be confused with the psycho-linguistic usage
of "deep structure".  We are NOT pretending to have captured some deep semantic
information, either by virtue of using predicate calculus terms, or because
of the ease with which the system can generate new relations.}
-- e.g. facts not readily apparent in the attribute-value pairs of some
aspect of the analogues.  A good example of this was the "embedded" hierarchy
in common to both types of trees.
Unless the descriptions of both types of trees already happened to have
this specification, (e.g. as appears in @Ref(Use-Hier),)
it is hard to see how (a naive)
feature matching could have notices, much less discovered, this relation.@FOOT{
Indeed, I am prepared to claim that
this common subtheory approach will in fact subsume this other model of analogy.
However, the purpose of this proposal is not to compare these
approaches @i(per se),
but rather to demonstrate considerations of other attempts to deal with
this problem of analogy.  Much more will be said in the thesis itself.}

Neither of these definitions, by themselves, is not terribly useful:
Notice neither tells why a given analogy is proposed,
and not any of the others which are still acceptable by their respective
definitions.
What makes a given analogy appropriate?
The criteria involved in this decision are quite subjective --
different people will propose quite different analogies to answer the
same question.
(There is no single answer to the question "Who is England's first lady?"
-- based on gender, many would insist it has to be Margaret Thatcher,
the female prime minister,
while others, seeing the "Spouse of the Head of State" role as more important,
would argue for her spouse, Dennis Thatcher.
With similiar arguments one could justify
Queen Elizabeth, or Prince Philip, or ... See @Cite[Hof81].)
Furthermore, even a single person may propose a variety of different
analogies depending on the current context:
A spoon is rather like a shovel in terms of its PTRANS-ing function,
whereas it is clearly closer to a knife in terms of size and 
general purpose.)

Despite this, the other analogizing systems mentioned above 
incorporated a single corpus of rules which collectively defined 
how to generate, (and/or evaluate) an analogy.
These rigidly defined what the program could produce.
One of the goals of this program, however, is flexibility --
to be able to accomodate different users, in diverse situations.
We achieve this versatility by employing
a collection of heuristics to guide its decisions
The user will be able to modify these rules to tune the program to
his "ideosyncrasies".
In fact, the overall system will 
include a module to help the user to adjust that body of heuristics,
honing it to produce analogies which fit his specifications.
We will return to this point later.

@Comment( from THESIS )
@Section(New Ideas)
@TAG(NewIdeas)
Below is a list of how this work on analogy is
different from previous AI work in this area.

@BEGIN(Itemize)
Definition of analogy@*
Rather than view an analogy as a direct mapping between corresponding aspects 
of the analogues, we take a model-theoritic approach -- defining
an analogy as a shared partial theory.
That is, two objects are considered analogous if they each satisfy the
same theory.

Our approach@*
We are taking an "Expert System" approach to the problem of analogy,
(with a few minor twists).
Expert systems are characterized as knowledge intensive systems, 
containing a large "knowledge base" of facts about the domain.
Here, that domain is analogy rather than, say, chemistry; and
this information is in the form of rules or heuristics.  
Part of Subsection @Ref(KB-Stuff) discusses the types of rules which are required.
(This approach is contrasted with the procedural attitude, in which
some inflexible, hand-crafted function is used to find the analogies.)

Individual analogies@*
This knowledge base will be easy to modify,
to adapt to the biases of individual users.  
This can be compared with other AI systems,
which can find (at most) those analogies which its designer considered worthwhile.
(Note this does NOT mean each user is forced to enter his particular rules.
He may, if he wishes, simply use my set of rules, which result in analogies
I consider reasonable.
The point is he has the option of alterring these rules,
to change the behaviour of the analogizer.
In fact, we even supply tools which facilitate this task.)@Foot{
As a powerful "side-effect" of both above points,
the analogical "matches" this
system will be able to find will not be restricted to
just those connections which are based on relations the user happened to include
in his description of the analogues.
Our system will be able to extend this languages in simple ways 
(i.e. to include derivable terms)
which can also be used for this match; and exploited afterward.}

@BEGIN(Multiple)
"Scholarly" research@*
Much AI work are built in an @i(ad hoc) manner,
to solve some small, particular job.  
The result is often of little use, beyond a crude existence proof that this
particular program could be built
-- i.e. the "simple" scaling up usually renders the system unusable.
Our goal, here, is a system which can be used
by many different people, over a variety of different domains of inquiry.

To have any chance of success,
it is important to first
"understand" the general idea of analogy, 
(as opposed to simply one man's version of this phenomena,)
before beginning the implementation.
We will, therefore, begin this research effort 
with a literary search which will 
cover work in psychology and philosophy as well as AI,
as well as conduct numerous preliminary dry labs.
We hope to glean the useful characteristics of analogies in this process,
which can be incorporated into the new system.
If (wildly) successful,
the result of this research will be of general interest,
especially to people who theoritically examine such issues,
(such as philosophers of science).
We will, however, be quite happy if these derived heuristics
simply prove to be a good starting set for the Heuristics KB;
and lead to the design of an efficient and powerful Analogizing algorithm.
Perhaps then this system will avoid the obsolescence which has characterized
all prior analogizing system.
@END(Multiple)
@END(Itemize)

@Comment( from SCENAR )
@Section(Scenario)

This short scenario will demonstrate some of the ways
analogy can be used to facilitate a Knowledge Acquisition (KA) task.
The examples included show
the type of reasoning (we consider) necessary for this process.

@SubSection(Overview of Situation and Goal)

The main characters in this story are
a hypothetical expert system, ES,
and an (assumedly human) expert on EMACS, U.
Their mutual goal is to increase ES's "understanding" of EMACS;
achieved by teaching it more EMACS commands,
and by improving its understanding of previously known commands --
so ES will "know" better when to apply a given command,
and precisely what it will do.
(At a meta-level,)
our research goal is understanding how to use analogies to facilitate
this educational process.

For ES to profitably understand the analogies U may use,
it must initially "know" a little about EMACS, 
(i.e. a few of its basic commands)
and something about editors in general
-- including a description their purpose,
what sorts of things they are able to do, 
a body of relevant vocabulary terms, etc.
(Appendix @Ref(StartingInfo) justifies this claim, 
explaining why ES must start with some core knowledge, but not too much.)

ES has access to two (complementary) forms
of knowledge about editors and EMACS.
First, it includes ("procedural") rules,
which ES's inference engine can directly use to solve particular problems.
(These solutions will be in the commands to type into EMACS.)
Appendix @Ref(Rules) lists a subset of these problem solving rules.
ES also has a knowledge base of ("declarative") body of facts about 
editors in general,
instantiated with some specific facts about (what it now knows about) EMACS.
(A sketch of this semantic network is included in Appendix @Ref(EditorFacts).)

Both of the Knowledge Bases -- of rules and facts --
will be modified by the KA, the Knowledge Acquisition front-end to ES.
In addition to incorporating new rules/nodes/links,
KA may alter existing facts.
For example, we will see cases where an If clause of a rule is generalized,
and where the "topology" of a network is rearranged.
(Note that KA will not touch certain things 
-- like the rule interpreter and other control procedures.)

We've been rather flippant with our use of the term "understanding" --
just what does it mean to claim that ES now "understands" a new command?
Rather than follow a rather unnatural, and complicated structural
approach@Foot{
That is, we might insist that ES be able to produce the TECO code
corresponding to each new command.
(Note this is similar to a "derivation from first principles".)
However, this is more than most people could do, and not necessary.}
we will use a totally behavior criterion:
does ES use the correct commands in a given situation?
We will say ES has incorporated a new command if it uses
that command appropriately 
-- meaning that ES types that command when an EMACS expert,
(trying to minimize his keystrokes,)
would type it.

Appendix @Ref(TestBed) lists a small
battery of test questions,
generated before beginning this KA task.
Note we're still not sure just how these
questions should be posed -- that is, in what language to describe 
the initial and desired file (and other things, like current windows,
cursor position, etc).
One possibility is to design a new high-level editor-independent specification --
whatever that would be.
Another would be to type the appropriate E or BRAVO commands, and have them
translated into EMACS.
Comments?

@SubSection(Examples)
@i<Here is where the scenario itself should go 
-- but that is still incomplete.  
Instead, I'll list some of the types of analogies KA should be able
to handle.>

@BEGIN(Verbatim)

Word commands are just like character commands,
	EXCEPT they use @i{M-x} rather than @i{C-x}.

S-expression commands are just like word commands,
	EXCEPT they use @i{M-C-x} rather than @i{M-x}.

Sentences are handled like lines,
	EXCEPT the command is @i{M-x} rather that @i{C-x},
	AND these commands refer to next sentence, not same line.

Buffers are like File Visiting,
	EXCEPT @i{C-X B} to switch about files (info lost when visiting)
	AND the file is not lost when next file is "encountered".

Windows are handled like Buffers,
	EXCEPT they are visible (and so have fewer lines...)
	AND they use @i{C-X C-O/1/2} to switch between them, (not @i{C-X B})

@END(Verbatim)

@Comment( from SCENAR )
@Section(Basing Predictions on Analogies)

So far the analogies had a single use -- for U to communicate a bundle
of facts to ES, simply and quickly.
In the scenario given, the full derivation which KA had to produce to
note such connections might simply be thrown away after the result
(eg how to move forward one word) has been deduced.

There are (at least) one reason to maintain this information:
It could be used by KA to draw feasible inferences,
based on what it has seen so far.  
These plausible inferences would suggest other analogous connections
of commands,
based on those old analogies.
For example, if KA later found that C-T meant to
transpose the (single) characters in front of and behind the cursor,
it might ask whether M-T meant to transpose words.
Indeed this the case.
@Foot{This implies some method to this EMACS madness.
<Here: Designed artifact assumption.>}

Eventually systems of known analogies could be analyzed,
searching for regularities.
One observation is that C- seems to refer to lowest (physical) level,
and M- to the next (often logical) level.  
(Not only was this true in the characters/words case,
but also for lines/sentences.)
From this, one might infer that, as C-N goes up one line,
that M-N would go up, say, one paragraph. 
(Note this suggestion is faulty -- oh well.)
<<Need better Example>>
@Section(Further tasks)

Now knowing about EMACS, try to learn E.
@BEGIN(Itemize)
(As with EMACS,)
when two E commands perform a similar function,
expect their invocations to be similar.@*
[Deep reasoning: designed by humans for humans...]@*
Ex: @G(a)F and @G(a)XF, or @G(a)D and @G(ab)D...

Same types of commands in E as in EMACS 
-- cursor movement, text substitution, movement, insertion...@*
[Deep reason: both are editors,
and the purpose of an editor is to perform some function...]

Pages in E are like narrow window in EMACS 
-- serving to restrict search, general context, ...@*
[This shortens otherwise long searches, movements, ...]@*
Difference: E's pages are static, defined in a file,
whereas narrow windows are dynamically assigned in EMACS.
@END(Itemize)
 
Onto harder problems --
It is relatively easy to map from EMACS to Bravo or E 
-- as they are all full screen editors.
What about TECO or SOS?
(Note this TTY editors make quite different assumptions:
here, typing is expensive, and should be avoided.  Hence the user must
explicitly state he wants to see X before seeing it.)

Go from here to -- knowledge about Text Editors -- to more general knowledge
about Text Formatters, like TEX or SCRIBE.  Core facts, about words, spaces,
etc, map over, but (few if any) actual commands will.

On another dimension,
consider the EMACS to representation languages mapping.
Both attempt to facilitate the storage and retrieval of information.
The major difference is generality: RLs are not restricted to dealing with text.

Consider now programming languages in general
-- which, like editors, are also based on sequences of commands, etc.

What about editors to real world map?
Files are like filing cabinets,
words like sequences of actions, ... etc.